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Beschreibung 

VERFAHREN / SOFTWARE- PRODUKT UND VORRI CHTUNGEN ZUR SIGNALISIERUNG DER MODIFIKATION 

VON BEARERVERBINDUNGEN MITTELS SIP PROTOKOLL 
5 

In der Vergangenheit haben sich zwei wesentliche Typen von 
Kommunikationsnetzen zur Ubermittlung von Inf ormationen her- 
ausgebildet: Paketorientierte (Daten-) Netze und leitungsori- 
entierte (Sprach-) Netze. Im Zuge der Konvergenz dieser bei- 
10 den Netztypen haben sich konvergente (Sprach-Daten-) Netze 
herausgebildet . Durch Zusammenschluss dieser unterschiedli- 
chen Netztypen entstehen hybride Netze, in denen der Gegen- 
stand der vorliegenden Erfindung mit besonders schonen Vor- 
teilen zum Einsatz kommt. 

15 

Leitungsorientierte Netze - auch Sprachnetze oder Telephon- 
netze genannt - sind auf die Ubermittlung von in der Fachwelt 
auch als Gesprach, Call oder Session bezeichneten kontinuier- 
lich stromenden (Sprach-} Inf ormationen ausgelegt. Die Uber- 

20 mittlung der Inf ormationen erfolgt hierbei iiblicherweise mit 
hoher Dienstgiite und Sicherheit. Beispielsweise ist fur Spra- 
che e'ine minimale - z.B. < 200 ms - Verzogerung (Delay) ohne 
Schwankungen der Verzogerungszeit (Delay-Jitter) wichtig, da 
Sprache bei Wiedergabe im Empf angsgerat einen kontinuierli- 

25 chen Informationsf luss erfordert. Ein Inf ormationsverlust 
kann deshalb nicht durch ein nochmaliges Ubermitteln der 
nicht ubermittelten Information ausgeglichen werden und ftihrt 
im EmpfangsgerSt ublicherweise zu akustisch wahrnehmbaren 
Storungen (z.B. Knacksen, Verzerrung, Echo, Stille) . In der 

30 Fachwelt wird die Ubermittlung von Sprache verallgemeinert 
auch als Echtzeit- (Ubermitt lungs-) Dienst bzw. als 'Realtime- 
Service 1 bezeichnet . 

Paketorientierte Netze - auch Datennetze genannt - sind auf 
35 die Ubermittlung von in der Fachwelt auch als 'Datenpaket- 
str5me f oder f Flow f bezeichneten Paketstrdmen ausgelegt. 
Hierbei muss ublicherweise keine hohe Dienstgiite garantiert 
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werden. Ohne garantierte Dienstgute erfolgt die Obermittlung 
der Datenpaketstrome z.B. mit zeitlich schwankenden Verzo- 
gerungen, da die einzelnen Datenpakete der Datenpaketstrome 
ublicherweise in der Reihenfolge ihres Netzzugangs ubermit- 
5 telt werden, d.h. die zeitlichen Verzogeruogen werden umso 
grofler, je mehr Pakete von einem Datennetz zu ubermitteln 
sind. In der Fachwelt wird die Ubermittlung von Daten deshalb 
auch als Obermittlungsdienst ohne Echtzeitbedingungen bzw. 
als 'Non-Realtime-Service ' bezeichnet. 

10 

Die Pakete unterscheiden sich Ublicherweise je nach Art des 
paketorientierten Netzes. Sie konnen beispielsweise als In- 
ternet, X.25 oder Frame Relay Pakete, aber auch als ATM Zel- 
len ausgebildet sein. Sie werden zuweilen auch als Nachrich- 
15 ten bezeichnet, v. a. dann, wenn eine Nachricht in einem Paket 
ubermittelt wird. 

Ein bekanntes Datennetz ist das Internet. Dieses wird wegen 
des dort zum Einsatz kommenden Internet Protokolls IP zuwei- 

20 len auch IP Netz genannt, wobei dieser Begriff grundsatzlich 
weit zu verstehen ist und alle Netze umfasst, in denen das IP 
Protokoll eingesetzt wird. Das Internet ist als offenes 
(Weitverkehrs-) Datennetz mit offenen Schnittstellen zur 
Verbindung von (zumeist lokalen und regionalen) Datennetzen 

25 unterschiedlicher Hersteller konzipiert. Es stellt eine vom 
Hers teller unabhangige Transportplattform zur Verfiigung. 

Verbindungen sind Kommunikationsbeziehungen zwischen zumin- 
dest zwei Teilnehmern zum Zweck einer - zumeist gegenseiti- 

30 gen, d.h. bi-direktionalen - InformationsUbermittlung. Der 

die Verbindung initiierende Teilnehmer wird Ublicherweise als 
'A-Teilnehmer 1 bezeichnet.. Ein durch eine Verbindung mit 
einem A-Teilnehmer in Verbindung gesetzter Teilnehmer heifit 
f B-Teilnehmer 1 . In einem verbindungslosen Netz reprasentieren 

35 Verbindungen zumindest die auf logisch abstrakter Ebene ein- 
deutige Beziehung zwischen A- und B-Teilnehmer, d.h. entspre- 
chend dieser Sichtweise stellen z.B. die verbindungslosen 
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Flows im Internet logisch abstrahierte Verbindungen dar (z.B. 
A-Teilnehmer = Browser und B-Teilnehmer = Web Server) . In 
einem verbindungsorientierten Netz reprasentieren Verbindun- 
gen zudem auf physikalischer Ebene eindeutige Wege durch das 
5 Netz, entlang denen die Inf ormationen ubermittelt werden. 

Im Zuge der Konvergenz von Sprach- und Datennetzen werden 
Sprachubermittlungsdienste und zunehmend auch breitbandigere 
Dienste wie z.B. Obermittlung von Bewegtbildinf ormationen 

10 ebenfalls in paketorientierten Netzen realisiert, d.h. die 
Obermittlung der bisher iiblicherweise leitungsorientiert 
Ubermittelten Echtzeitdienste erfolgt in einem konvergenten 
Netz - auch Sprach-Daten-Netz genannt - paketorientiert, d.h 
in Paketstromen. Diese werden auch Echtzeitpaketstrome ge- 

15 nannt. Die Obermittlung von Sprachinf ormationen liber ein 

paketorientiertes IP Netz wird dabei auch mit 'VoIP 1 (Voice 
over IP) gekennzeichnet . 

In den internationalen Standardisierungsgremien IETF (Inter- 
20 net Engineering Task Force) und ITU (International Telecommu 
nications Union) mehrere verteilte Architekturen fttr Sprach- 
Daten-Netze beschrieben. Allen ist gemeinsam, dass die Call 
Control Ebene und die Resource Control Ebene funktional deut 
lich voneinander getrennt sind und meist sogar auf unter- 
25 schiedlichen Hardware Plattf ormen realisiert werden. 

Die Call Control Ebene umfasst dabei zumindest einen (optio- 
nalen) Call Controller, dem u.a. folgende Funktionen zuge'ord 
net sind: 

30 - Address Translation: Umsetzung von E.164 Telephonnummern 
und anderen Alias Adressen (z.B. Rechnernamen) auf Trans- 
portadressen (z.B. Internetadressen) . 

- Admission Control (optional) : Grunds&tzliche Zuiassig- 
keitsprUfung, ob und in welchem Umfang (z.B. VoIP fahige) 

35 Einrichtungen das Kommunikationsnetz nutzen dilrfen. 

- Bandwidth Control (optional) : Verwaltung von Oberraitt- 
lungskapazitaten. 
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- Zone Management: Registrierung von (z.B. VoIP fahigen) 
Einrichtungen und Bereitstellung obiger Funktionen fur al- 
le beim Call Controller registrierten Einrichtungen. 

5 Optional konnen einem Call Controller zudem folgende Funktio- 
nen fallweise zugeordnet werden: 

- Call Control Signaling: Alle Signalisierungsnachrichten 
werden von zumindest einem Call Controller vermittelt, 
d.h. alle Einrichtungen schicken und erhalten Signalisie- 

10 rungsnachrichten nur Uber den Call Controller. Ein direk- 
ter Austausch von Signalisierungsnachrichten zwischen den 
Einrichtungen ist untersagt. 

- Call Authorization: Zulassigkeitspruf ung ftir eingehende 
und ausgehende Calls. 

15 - Bandwidth Management: Steuerung der zulassigen Anzahl von 
Einrichtungen, die gleichzeitig das Kommunikationsnetz 
nutzen dtirfen. 

- Call Management: Verwaltung einer Liste bestehender Ge- 
sprMche, urn z.B. ein Besetzzeichen erzeugen zu konnen, 

20 falls dies von der Einrichtung selbst nicht erzeugt werden 

kann. 

- Alias Address Modification: Rlickgabe einer modif izierten 
Alias Adresse, bspw. mit einer H. 225.0 Nachricht ACF (Ad- 
mission Conf irmation) . Diese Adresse muss der Endpunkt bei 

25 Verbindungsaufbau verwenden. 

- Dialed Digit Translation: Obersetzung der gewahlten Zif- 
fern in eine E.164 Telephonnummer oder eine Nummer aus ei- 
nem privaten Nummerierungsschema. 

30 Beispiele fiir Call Controller stellen der von der ITU in der 
H.323 Standard Familie vorgeschlagene 'Gatekeeper 1 oder der 
von der IETF vorgeschlagene T SIP Proxy 1 dar. Wird ein groBe- 
res Kommunikationsnetz in mehrere Domanen - auch 1 Zonen 1 
genannt - gegliedert, kann in jeder Domane ein separater Call 

35 Controller vorgesehen werden. Eine Domane kann auch ohne 
einen Call Controller betrieben werden. Sind mehrere Call 
Controller in einer Domane vorgesehen, soil nur ein einziger 
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von diesen aktiviert sein. Ein Call Controller ist aus logi- 
scher Sicht getrennt von den Einrichtungen zu sehen. Physika- 
lisch muss er jedoch nicht in einer separaten Call Controller 
Einrichtung realisiert sein, sondern kann auch in jedem End- 
5 punkt einer Verbindung (beispielsweise ausgebildet als H.323 
Oder SIP Endpunkt, Endgerat, Media Gateway, Multipoint 
Control Unit) Oder auch einer primar zur programmgesteuerten 
Datenverarbeitung ausgebildeten Einrichtung (beispielsweise: 
Rechner, PC, Server) vorgesehen werden. Auch eine physika- 
10 lisch verteilte Realisierung ist moglich. 

Ein alternatives Beispiel ist ein Media Gateway Controller, 
dem ublicherweise die optionalen Funktionen Call Control 
Signaling and Call Management zugeordnet werden. Weiterhin 
15 ist die Zuordnung einer Funktion Signaling Conversion zur 
Umsetzung unterschiedlicher (Signalisierung-) Protokolle 
denkbar, was z.B. an der Grenze von zwei unterschiedlichen 
Netzen, die zu einem hybriden Netz zusammengeschlossen sind, 
erforderlich sein kann. 

20 

Die Resource Control Ebene umfasst zumindest einen Resource 
Controller, dem u.a. folgende Funktionen zugeordnet sind: 

- Capacity Control: Steuerung des dem Kommunikationsnetz 
durch Paketstrome zugefuhrten Verkehrsvolumens, z.B. durch 

25 Kontrolle der Ubermittlungskapazitat einzelner Paketstro- 
me. 

- Policy Activation (optional): ggf. fur einen priorisierten 
Paketstrom Resourcen im Kommunikationsnetz far dessen 0- 
bermittlung reservieren. 

30 - Priority Management (optional) : Prioritatskennzeichen in 
den Paketen entsprechend der Prioritat ihrer PaketstrSme 
setzen, kontrollieren und gegebenenf alls korrigieren, 
falls die Pakete bereits mit Prioritaten gekennzeichnet 
sind. 

35 

Der Resource Controller wird auch als 1 Policy Decision Point 
(PDP) 1 bezeichnet. Er ist beispielsweise innerhalb von sog. 
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Edge Routern - auch Edge Device, Zugangsknoten oder bei Zu- 
ordnung zu einem Internet Service Provider (ISP) auch Provi- 
der Edge Router (PER) genannt - realisiert. Diese Edge Router 
konnen auch als Media Gateway zu anderen Netzen ausgebildet 
5 sein, mit denen die Sprach-Daten-Netze verbunden werden. 

Diese Media Gateway sind dann sowohl mit einem Sprach-Daten- 
Netz als mit den anderen Netzen verbunden und dienen intern 
der Umsetzung zwischen den unterschiedlichen (Obermittlungs-) 
Protokollen der verschiedenen Netze. Der Resource Controller 
10 kann auch nur als Proxy ausgebildet sein und Resource Cont- 
roller relevante Informationen an eine separate Einrichtung 
weiterleiten, auf der die relevanten Informationen entspre- 
chend einer Funktion des Resource Controllers bearbeitet 
werden. 

15 

Zur Koordination der beiden Ebenen wird ublicherweise eine 
Mehrzahl von Nachrichten versendet, die lediglich zur Abstim- 
mung der beteiligten Komponenten untereinander , jedoch nicht 
zur Ubermittlung der "eigentlichen" Informationen zwischen 

20 den Endgeraten dienen. Diese mit den Nachrichten ttbermittel- 
ten Informationen werden ublicherweise als Signalisierungsin- 
formationen, Signalisierungsdaten bzw. schlicht als Signal!- 
sierung bezeichnet. Der Begriff ist dabei weit zu verstehen. 
So sind z.B. neben den Signalisierungsnachrichten auch die 

25 Nachrichten gemaB dem RAS Protokoll, die Nachrichten gemafl 
dem ITU-Standard H.245 zur Steuerung von Nutzkanaien beste- 
hender Gesprache sowie alle weiteren ahnlich ausgebildeten 
Nachrichten umfasst. Das Signalisierungsprotokoll fttr den 
Verbindungsaufbau (Call Setup) und -abbau (Call Release) nach 

30 der ITU ist z.B. im Standard H. 225.0 beschrieben, das nach 

der IETF im RFC2543 ("SIP: Session Initiation Protocol") bzw. 
dessen Uberarbeitungen RFC2543bis0x oder RFC32 61. Die "ei- 
gentlichen Informationen" werden zur Unterscheidung von der 
Signalisierung auch Nutzinformationen, Payload, Medieninfor- 

35 mationen, Mediendaten oder schlicht Medien genannt. Kommuni- 
kationsbeziehungen, die zur Ubermittlung der Signalisierung 
dienen, werden im weiteren auch als Signalisierungsverbindun- 
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gen bezeichnet. Die zur ttbermittlung der Nutzinformationen 
eingesetzten Kommunikationsbeziehungen werden z.B^. Sprechver- 
bindung, Nutzkanalverbindung oder - vereinfacht - Nutzkanal, 
Bearerchannel Oder schlicht Bearer genannt. In diesem Zusam- 
5 menhang versteht man unter out-of-band bzw. outband die Uber- 
mittlung von Inf ormationen auf einem anderen Weg / Medium als 
den im Kommunikationsnetz zur Obermittlung von Signalisie- 
rungs- und Nutzinformationen vorgesehenen. Insbesondere ist 
hiervon eine lokale Konf iguration von Einrichtungen vor Ort 
10 umfasst, die z.B. mit einer lokalen Steuereinrichtung vorge- 
no.mmen wird. Demgegeniiber werden bei in-band Inf ormationen 
auf dem gleichen Weg / Medium, ggf . logisch getrennt von den 
betrachteten Signalisierungs- und Nutzinformationen, tibermit- 
telt. 

15 

Das prinzipielle Zusammenwirken der beiden Ebenen sei am 
Beispiel eines Call Setup zwischen zwei als Teilnehmerendge- 
rate ausgebildeten VoIP Einrichtungen erlautert. Dabei wird 
zunachst von einem homogenen Sprach-Daten-Netz ausgegangen. 

20 

Innerhalb oder teilweise auch zeitlich vor dem eigentlichen 
Call Setup laufen bei Einwahl eines Endgerats in das IP-Netz 
(z.B. uber einen Internet Service Provider) die Schritte 
Authentisierung, Autorisierung und (Start des). Accounting ab. 

25 Diese sogenannte T AAA* Funktionalitat wird ublicherweise 

durch den Zugriff auf eine Subscriber-Datenbank, in der alle 
Nutzer mit ihren Kennungen, Passwortern, Rechten, etc. ge- 
speichert sind, realisiert. Dieser Zugriff ist langsam und 
vergleichsweise komplex. In den heutigen "Best Effort" IP 

30 Netzen findet dieser AAA Vorgang normalerweise einmal wahrend 
des Einwahlens des Nutzers statt. Eine weitere Authentisie- 
rung erfolgt bei Einsatz eines Call Controllers, wenn sich 
das Endgerat beim Call Controller des Internet Service Provi- 
ders registriert. Nach dem ITU-Standard H.323 wird diese 

35 Authentisierung bzw. Registrierung eines Endgerats beim zuge- 
ordneten Gatekeeper gemafi dem RAS (Registration, Admission, 
Status) Protokoll durchgefiihrt, das im ITU-Standard H. 225.0 
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beschrieben ist. 

Der eigentliche Call Setup beginnt iiblicherweise damit, dass 
in einem ersten Schrit-t die Endgerate der Teilnehmer ihre 
5 Fahigkeiten (z.B. Liste der untersttitzten CODEC) austauschen, 
inn die benotigten Ressourcen (z.B. Bandbreite) und die ge.for- 
derte QoS (z.B. Delay, Jitter) zu bestimmen. Die Endgerate 
sind bei Sprachtelephonie z.B. als IP Telephone oder VoIP 
Client Software ausgebildet, bei Online-Video konnte eines 
10 der Endgerate ein Content- bzw. Application-Server sein, z.B. 
im Netz des Internet Service Providers (ISP) . 

Der Austausch der Signalisierungsnachrichten erfolgt entweder 
direkt zwischen den Endgeraten oder unter Vermittlung eines 

15 Call Controllers. Hierbei ist bei jedem Call fUr jedes Endge- 
rat und fur jede Ubertragungsrichtung individuell festgelegt, 
welche Variante zum Einsatz kommt-.Die erste Variante wird in 
der H.323 Terminologie auch als 'Direct Endpoint Call Signal- 
ing 1 und die zweite als r Gatekeeper Routed Call Signaling 1 

2 0 bezeichnet. Bei Direct Endpoint Call Signaling konnen an 
einen Call Controller ggf. Kopien ausgewahlter Signalisie- 
rungsnachrichten ubermittelt werden, so dass ein Call Cont- 
roller auch bei dieser Variante haufig Kenntnis von den zwi- 
schen den Endgeraten abgestimmten Ressourcen- und QoS- 

25 Anforderungen hat. Diese Anforderungen werden jedoch von ihm 
selbst nicht aktiv beeinflusst oder verifiziert. 

Alternativ kann auch das SIP Protokoll zum Einsatz kommen, 
und zwar sowohl fiir IP Ger&te als auch zwischen Media Gateway 

30 Controllers Im zweiten Fall wird das SIP Protokoll mit 
SIPJT (SIP for Telephones) bezeichnet, das im Standard 
RFC3372 beschrieben ist. Wenn ein Call mit Hilfe des SIP 
Protokolls aufgebaut wird, so wird zwischen den beiden Seiten 
der Verbindung iiblicherweise eine Beschreibung des Bearers 

35 ausgetauscht . Dazu wird das Session Description Protocol 

(SDP) nach dem Standard RFC2327 eingesetzt. Dieser Einsatz 
ist u.a. im Standard RFC3264: "An Offer/Answer Model with the 
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20 



25 



Session Description Protocol (SDP) ■ beschrieben. Wichtig sind 
dabei vor allem folgende Bearer Daten: 

- IP Adresse der Bearer Connection 

- RTP/UDP Port der Bearer Connection (je nachdem, ob eine 
Sprach- oder Datenubertragung vorliegt) 

- Codec (s), die fttr die Sprach bzw. Datenubertragung benutzt 
werden (konnen) 

- Streammode der Bearer Connection 



In einem zweiten, optionalen Schritt kann die derart abge- 
stimmte Ressourcen- und QoS-Anforderung direkt von den Endge- 
raten der Teilnehmer an ihren zugeordneten Resource Control- 
ler ubermittelt werden. Nach Prufung der Ressourcen- und QoS- 
15 Anforderung wird von dem Resource Controller eine Bestatigung 
(oder Ablehnung) an das Endgerat zuruckgeschickt . 

In einem dritten, ebenfalls optionalen Schritt wird im Edge 
Router und gegebenenfalls weiteren Routern im Netz eine Poli- 
cy aktiviert, mit der diese Router prUfen und gewahrleisten, 
dass der vom Endgerat verursachte Verkehr innerhalb der Gren- 
zen liegt, die in der Anforderung spezifiziert wurden. Ein 
Beispiel fur einen derartigen Reservierungsmechanismus ist 
RSVP (resource Reservation Protocol) . 



Zusammen fas send kann der Function Split zwischen den beiden 
Ebenen so beschrieben werden, dass der Resource Control Ebene 
lediglich die Funktionen zugeordnet sind, die zur Ubermitt- 
lung von Nutzinformationen erforderlich sind, wahrend von der 

30 Call Control Ebene die Intelligenz zur Steuerung der Resource 
Control Ebene umfasst ist. Mit anderen Worten: Die Einrich- 
tungen der Resource Control Ebene besitzen moglichst keine 
Netzsteuerungsintelligenz und konnen in der Folge wirtschaft- 
lich besonders vorteilhaft auf separaten Hardware Plattformen 

35 realisiert werden. Dies ist wegen der im Vergleich zu Call 

Control Ebene hoheren Installationszahlen in dieser Ebene ein 
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besonders schoner Vorteil.- 

Sowohl in konvergenten Sprach-Daten-Netzen als auch in hybri- 
den Netzen, die.z.B. durch einen Zusaminenschluss eines kon- 
5 vergenten Sprach-Daten-Netzes mit einem konventionellen lei- 
tungsorientierten Sprachnetz gebildet werden, entstehen bei 
der Ubermittlung von Informationen - insbesondere der in 
EchtzeitpaketstrSmen - neue technische Problemstellungen 
aufgrund der neuen bzw. unterschiedlichen Technologies die 
10 in den jeweiligen Netztypen zum Einsatz kommen. 

Es ist Aufgabe der Erfindung, zumindest eines dieser Probleme 
zu erkennen und durch Angabe von zumindest einer LSsung den 
Stand der Technik zu bereichern. 

15 

Die Erfindung stellt sich die Frage, ob nach dem Aufbau eines 
Calls liber das SIP Protokoll weiterhin alle Features genutzt 
werden konnen, die derzeit aus der Telefonie bekannt sind. 
Bei vielen dieser Features sind dabei Modif ikationen des IP 
20 Bearers notwendig, z.B.: 

- Umschaltung der Sprachverbindung auf Dateniibertragung far 
Fax- und Modem-Anwendungen 

- Bearer Redirection (z.B. fur die Umleitung der Verbindung 
25 auf ein Announcement) 

- Neuaushandlung des Sprach-/Datencodecs wahrend des Calls 
(Mid Call Codec Negotiation) 

- Call Hold und Call Retrieve 

30 Alle oben genannten Features haben einen neuen Austausch der 
Bearer Beschreibung in Form einer SDP Session zur Folge, die 
in einer SIP/SIPJT :Re-INVITE Meldung bzw. der zugehorigen 
SIP/SIPJT Response transportiert wird. Dabei wird die Ursache 
fUr die Bearer Modifikation weder im SIP Protokoll noch in 

35 der SDP Session explizit Ubertragen, sondern muss auf der 

empfangenden Seite aus den SDP Daten, mit denen lediglich die 
Bearer Modifikation angezeigt wird, regeneriert werden. Diese 
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Regenerierung ist aber nicht imirier eindeutig m5glich. Bei- 
spielsweise kann es in folgenden Fallen Probleme geben: 

- Wird der Codec einer Sprachverbindung geandert, kann dies 
5 ein Codec Switchover fUr Fax/Modem, ein Switchover auf ei- 

nen neuen Sprachcodec, oder aber auch eine Neuaushandlung 
des Sprachcodecs wahrend des Calls (Mid Call Codec Negoti- 
ation) sein. 

10 - Werden mehrere Features kombiniert, ist es zuweilen nicht 
mehr moglich, anhand der neu empfangenen SDP Session zu 
ermitteln, welche Features kombiniert wurden. Eine SDP 
Session fur Bearer Redirect sieht beispielsweise genauso 
aus wie eine SDP Session, die fur gleichzeitiges Call 

15 Retrieve und Bearer Redirect geschickt wird. 

Ohne eindeutige Regenerierung der Ursache kann auf der emp- 
fangenden Seite jedoch keine aussagekraf tige Mitteilung ge- 
troffen werden (z.B. am Display eines Telephons oder auf der 
20 Bedienoberflache eines Software Telephon Clients), welches 
Feature gerade von der sendenden Seite aktiviert worden ist. 

Eine Losung fur diese der Erfindung zugrunde liegende Prob- 
lems! tuation ist in den Patentanspruchen angegeben. 

25 

Mit dieser Losung sind eine Vielzahl von Vorteilen verbunden: 

- Durch Obermittlung der Ursache der Bearer Modifikation 
wird eine uneingeschrankte Nutzung verschiedenster Tele- 

30 phonie Leistungsmerkmale ermoglicht . 

- Das bisherige, zum Teil sehr aufwandige, deduktive Ermit- 
teln der Ursache der Bearer Modifikation anhand der uber- 
mittelten Bearer Modifikation entfallt. 

35 

- Durch die (eindeutige) Angabe der Ursache (n) der Bearer 
Modifikation konnen die von der sendenden Seite aktivier- 
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ten Features auch dann bestimmt und angezeigt werden, wenn 
diese nicht deduktiv aus der Bearer Modifikation regene- 
rierbar sind. 

5 Weitere vorteilhafte Ausgestaltungen der Erfindung ergeben 
sich aus den unter- oder nebengeordneten Anspriichen. 

Das Interworking zwischen den Protokollen SIP / SIPJT und den 
Protokollen BICC CS2 / ISUP+ (siehe ITU-T Recommendation 

10 Q. 1902.x, Bearer Independent Call Control Protocol CS2) wird 
grundlegend vereinfacht, wenn das Protokollelement als action 
Parameter mit folgenden Werten ausgebildet ist: connect- 
backward, connect- forward, connect -forward-no-notification, 
connect- forward-plus-notification, connect- forward-no not if i- 

15 cation-plus-selected codec, connect forward-plus- 
notification-plus-selected codec, connected, switched, se- 
lected-codec, modify-codec, successful-codec-modification, 
codec-modification-failure, mid-call-codec-negotiation, mod- 
ifyr to-selected-codec-information, mid-call-codec- 

20 negotiation-failure, redirect-backwards-request, redirect- 
forwards-request, redirect-bearer- release-request, redirect- 
bearer-release-proceed, redirect-bearer-release-complete, 
redirect-cut-through-request, redirect-bearer-connected- 
indication, redirect-f ailure, remote-hold, remote-hold-ack, 

25 remote-retrieval, remote-retrieval-ack, weil der action Para- 
meter so problemlos in die BICC CS2 / ISUP-f Informationsele- 
mente "Action Indicator" und "Bearer Redirection Indicators" 
umgesetzt werden kann. 

30 Die Erfindung wird im folgenden anhand von weiteren Ausfuh- 
rungsbeispielen, die auch in den Figuren dargestellt sind, 
erlautert. Dabei zeigt: 

Figur 1 eine Anordnung zur Durchfuhrung des erf indungsgema- 
35 &en Verfahrens mit einem hybriden Kommunikations- 

netz, bestehend aus einem paketorientierten, integ- 
rierten Sprach-Daten-Netz und einem leitungsorien- 
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tierten Sprachnetz, die durch zwischengeschaltete 
Media Gateways und Media Gateway Controller verbun- 
den sind, sowie zwei Endpunkten einer Informations- 
Ubermittlung 

5 

Figur 2 ein Ablauf diagramm, in dem eine Ausfiihrung der 
Erfindung exemplarisch aufgezeigt ist 

In Figur 1 ist eine beispielhaf te Anordnung zur Durchfuhrung 
10" des erf indungsgemaften Verfahrens dargestellt. Sie"umfasst ein 
leitungsorientiertes Netz PSTN und ein Kommunikationsnetz IN, 
das vorzugsweise als integriertes Sprach-Daten-Netz SDN aus- 
gebildet ist. Die beiden Netze PSTN, IN sind zu einem hybri- 
den Netz zusammengeschlossen. Das Netz IN ist vorzugsweise 
15 als ein IP Netz (z.B. das Internet) ausgebildet und umfasst 
als Call Controller einen SIP Proxy SP. 

Der Zusammenschluss des leitungsorientierten Bearers TDM mit 
dem paketorientierten Bearer RTP/RTCP wird durch ein zwi- 

20 schengeschaltetes Media Gateways MG zur Konvertierung zwi- 
schen unterschiedlichen, netzspezif ischen Nutzkanaltechnolb- 
gien RTP/RTCP (Real Time [Control] Protocol) und TDM (Time 
Devision Multiplex), der Zusammenschluss der Signalisierung 
SS7 des Netzes PSTN mit der Signalisierung SIP des Netzes IN 

25 durch zwischengeschaltete Media Gateway Controller MGC1-3 zur 
Konvertierung zwischen unterschiedlichen netzspezif ischen 
Signalisierungsprotokollen SIP (Session Initiation Protocol) 
bewirkt. Dabei kommt zwischen den Controllern MGC t und MGC 3 
ein Protokoll BICC CS2 / ISUP+ und zwischen den Controllern 

30 MGC 3 und MGC 2 ein Protokoll SIPJT (SIP for Telephones) zum 
Einsatz . 

Das Gateway MG wird von dem ihm zugeordneten Controller MGC a 
durch ein - vorzugsweise international genormtes - Protokoll, 
35 z.B. MGCP (Media Gateway Control Protocol) oder H.248 gesteu- 
ert. Es ist Ublicherweise als separate Einheit realisiert, 
die auf einer anderen physikalischen Einrichtung / Hardware 
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Plattform zum Ablauf kommt als die Controller MGC. 

An das Netz PSTN A ist ein Teilnehmer A rait Hilfe eines her- 
kommlichen Telephons T, an das Netz IN ein Teilnehmer B mit 
5 der eines SIP fahigen Telephons - z.B. eines in Software 
realisierten SIP Clients SC - angeschlossen, zwischen denen 
als Bearer eine end-to-end Nutzverbindung TDM, RTP/RTCP ein- 
gerichtet ist. 



10 In Figur 2 ist die Abfolge von SIP Nachrichten (l)-(4) zum 
Aufbau eines Bearers zwischen zwei SIP Clients A, B und von 
Nachrichten (5) -(17) zur Modifikation des Bearers durch Wei- 
terleitung des Call von dem SIP Client B zu einem SIP Client 
C dargestellt, in der die Nachrichten (5), (6), (12), (13), 

15 (15) und (16) gemaft einem erf indungsgemSBen SIP Protokoll ausge- 
■ bildet sind. 

Es sei betont, dass die derart aufgezeigten Ausfuhrungen der 
Erfindung trotz ihre teilweise sehr detailgetreuen Darstel- 

20 lung von konkreten Netzszenarien lediglich beispielhaf ter 

Natur und nicht einschrankend zu verstehen sind. Dem Fachmann 
ist klar, dass die Erfindung bei alien denkbaren Netzkonfigu- 
rationen, insbesondere anderen Interworking Szenarien sowie 
weiteren paketorientierten Netzen zum Einsatz kommen kann wie 

25 z.B. Intranet, Extranet, einem lokalen Netz (Local Area Net- 
work - LAN) oder einem, z.B. als Virtuelles Privates Netz 
(VPN) ausgebildeten f irmeninternen Netz (Corporate Network) . 



30 



In dem Ausf iihrungsbeispiel nach Figur 1 werden das SIP Proto- 
koll sowie sein Derivat SIP_T in einem komplexen, hybriden 
Netzszenario eingesetzt, bei dem die Netzsignalisierung mehr- 
fach zwischen den Protokollen SIP, SIP_T, BICC CS2 / ISUP+, 
SS7 (ISUP) umgesetzt wird. Dabei wird vom Controller MGC 3 
eine Umsetzung zwischen dem Protokoll BICC CS2 / ISUP+ und 
35 dem erf indungsgemafi zumindest ein Protokoll element - insbe- 
sondere Parameter action - zur Anzeige der Ursache von Modi- 
fikationen des Bearers TDM, RTP/RTCP umfassenden SIP_T Proto- 
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koll bewirkt. 

Dazu wird in ausgew&hlten SIPJT Nachrichten im Message Body 
neben ein ISUP MIME Content eine SDP Session tibertragen (mi- 
5 xed content; siehe RFC2 04 6 "Multipurpose Internet Mail Exten- 
sions (MIME) Part Two: Media Types", und RFC3204 "MIME media 
types for ISUP and QSIG Objects" ), in deren SDP Body ein 
"Content-Disposition" Header Field gemSB RFC2183 eingebettet 
ist, das jeweils zumindest ein erf indungsgemaBes Protokoll- 

10 element zur tJbermittlung der Ursache(n) einer Bearer Modifi- 
kation umfasst. Der "disposition-type" dieses Header Field 
wird auf "session" gesetzt. Zudera wird als neues Protokoll- 
element ein neuer "disposition-parameter" namens "action" zur 
Angabe der Ursache der Bearer Modifikation eingefuhrt und in 

15 das "Content-Disposition" Header Field eingebettet. 

Zur Kombination mehrerer Ursachen/ Features konnen mehrere 
"action" parameter in einem "Content-Disposition" Header 
Field tibertragen werden. In Anlehnung an die ITU_T Standard 

20 Q. 765.5 (Signalling System No. 7 - Application transport 

mechanism for Bearer Independent Call Control) , welcher gemafl 
dem ITU-T Standard Q. 1902.x BICC CS2 (bearer independent call 
control - capability set 2) z.B. zwischen Call Controllern 
MGC zum Einsatz kommt, umfasst der Wertebereich des "action" 

25 parameters folgende Werte: connect-backward, connect-forward, 
connect- forward- no-notification, connect- forward-plus- 
notification, connect- forward-no notification-plus-selected 
codec, connect forward-plus-notification-plus-selected codec, 
connected, switched, selected-codec, modify-codec, success- 

30 ful-codec-modification, codec-modification-failure, mid-call- 
codec-negotiation, modify-to-selected-codec-information, mid- 
call-codec-negotiation- failure, redirect-backwards-request, 
redirect-forwards-request, redirect-bearer-release-request, 
redirect-bearer-release-proceed, redirect-bearer-release- 

35 complete, redirect-cut- through-request, redirect-bearer- 

connected-indication, redirect-f ailure, remote-hold, remote- 
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hold-ack, remote-retrieval, remote-retrieval-ack . 

Ein beispielhaftes erf indungsgemalies "Content-Disposition" 
Header Field sieht sieht in diesem Beispiel wie folgt aus 
5 (das erfindungsgem^Be Protokollelement ist durch Fettdruck 
hervorgehoben) : 



10 



Content-Disposition: session 

; action=remote-retrieval 
; action=redirect-forwards -request 



Wegen der Erfindung ergibt sich der schone Vorteil, dass die 
BICC CS2 / ISUP+ Informationselemente "Action Indicator" und 
"Bearer Redirection Indicators" sehr einfach mit aussagekraf- 
15 tigen Werten befiillt werden konnen. 

Als weiteres Ausfuhrungsbeispiel der Erfindung wird ein Bea- 
rer Modifikation zwischen drei Teilnehmern A, B, C, die alle 
als SIP Clients SC ausgebildet sein, beschrieben. Der Ablauf 
20 dieses Szenarios ist in Figur 2 dargestellt. Zum vereinfach- 
ten Verstandnis der Erfindung sind in Figur 2 nur SIP Clients 
SC dargestellt und SIP Proxy Server SP weggelassen. 

Bei diesem Beispiel wird zunachst eine Verbindung/Call zwi- 
25 schen den SIP Clients A und B aufgebaut - Nachrichten (1)- 
(4) . Anschliefiend legt der SIP Client B den Call auf Hold - 
Nachrichten (5) -(7) - und ruft dann den SIP Client C an - 
Nachrichten (8) -(11). Nach diesem Anruf schickt der SIP 
Client B eine "Re-INVITE" Nachricht (12) zum SIP Client A, 
30 mit der er gleichzeitig das Call Hold aufhebt (Call Retrieve) 
und den von dem SIP Client A ausgehenden Call Stream auf den 
SIP Client C (Bearer Redirect) umlenkt - Nachrichten (12)- 
(14). SchlieBlich schickt der SIP Client B eine "Re-INVITE" 
Nachricht (15) zum SIP Client C, mit der er den von dem SIP 
35 Client C ausgehenden Call Stream auf SIP Client A (Bearer 

Redirect) umgelenkt wird. Das Endergebnis ist ein Call Trans- 
fer vom SIP Client B zum SIP Client C. Der SIP Client A kann 
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nun mit dem SIP Client C sprechen. 

Nachfolgend werden die Nachrichten (1)-(17) dargestellt, 
wobei in diesen auf die Darstellung von "Via" Header Fields 
verzichtet wird, weil diese fttr den SDP Body Content der SIP 
Nachrichten transparent sind. Dabei wird eine SDP Session in 
einer SIP Message als MIME Message Body gemafi RFC2045 trans- 
portiert. Im Falle von SDP wird in diesem Beispiel der Con- 
tent des SIP Message Body mit folgenden SIP Header Fields 
spezifiziert : 

- "MIME-Version": 
fest auf "MIME-Version: 1.0" gesetzt (= RFC2045) - kann 
optional auch weggeiassen werden. 

15 

- "Content-Length" : 

spezifiziert die Lange des gesamten Message Body. 

- "Content-Type" : 

20 spezifiziert den Typ des Contents in Form eines Media Type 

und Media Subtype. Im Falle von SDP sieht der Content Type 
folgendermaften aus: 



5 



10 



25 



media type = * application" 
media subtype = *SDP" 
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Eine beispielhaf te Nachricht SIP : Re-INVTTE iait SDP sieht 
demnach wie folgt aus: 



10 



15 



20 



INVITE sip: "E.164 (B-Tln) "@"IP-Addr (B-Tln) ";user=phone 
SIP/2.0 

From: <sip: "E.164 (A-Tln) "@"IP-Addr (A-Tln) ";user=phone> 
To: <sip: "E.164 (B-Tln) "@"IP-Addr (B-Tln) " ;user=phone> 
Call-ID: a84b4c76e66710 
CSeq: 8348 INVITE 

Contact : <s ip : "E . 1 64 (A-Tln ) " @ "IP-Addr (A-Tln ) " ; user=phone> 

MIME -Version: 1.0 
Content-Type: application/SDP 
Con tent -Length : 166 

v=0 

o=hiQ9200 2890844526 2890844527 IN IP4 " IP-Addr (A-Tln) " 
s= 

c=IN IP4 aaa.bb. cc. dd 
t=0 0 

m=audio 2673 RTP/AVP 4 
a=rtpmap:4 G723/8000 
a=sendrecv 



35 



25 Zur Ubertragung der Ursache einer Bearer Modif ikation wird 

fur SDP beispielsweise das "Content-Disposition" Header Field 
gemaft RFC2183 eingesetzt, dessen Syntax derjenigen des vorhe- 
rigen Ausfuhrungsbeispiels entsprechen kann. 

30 Eine beispielhaf tes "Content-Disposition" Header Field, das 
wegen einer Bearer Redirection gesendet wird, sieht demnach 
in obiger Nachricht SIP:Re-INVITE, eingebettet in ein SDP 
Protokoll, wie folgt aus (das erf indungsgemafte Protokollele- 
ment ist durch Fettdruck hervorgehoben) : 



40 



[MIME-Version : 1.0] 
Content-Type : application/SDP 
Content -Disposition: session 

; action=redirect-forwards -request 
Content-Length : xxx 



FUr das AusfUhrungsbeispiel ergeben sich demnach folgende 
Nachrichten (1)-(17), wobei die erf indungsgemafien Protokoll- 
elemente in den Nachrichten (5), (6), (12), (13), (15) und 
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(16) entsprechend hervorgehoben sind: 

Nachricht (1): INVITE Client A -> Client B 
INVITE sip: ClientB@gmx.com SIP/2.0 
5 From: sip :ClientA@munichnet .com;tag=lc24841 
To : s ip : ClientBggmx . com 
Call-ID: call-973574144@munichnet.com 
CSeq: 1 INVITE 

Contact : <sip: ClientA@pc4 3 .munichnet . com> 
10 Content-Type: application/sdp 
Content-Length; 161 

v=0 

o=ClientA 2890844526 2890844526 IN IP4 pc43.munichnet.com 
15 s= 

c=IN IP4 192.0.2.101 
t=0 0 

m=audio 49172 RTP/AVP 8 4 
a=r tpmap : 8 PCMA/ 8000 
20 a=rtpmap:4 G723/8000 

Nachricht (2): 180 Ringing Client B -> Client A 
SIP/2.0 180 Ringing 

From: sip: ClientA@munichnet . com; tag=lc24841 
25 To: sip:ClientB@gmx.com;tag=0da40dd4-81553525 
Call-ID: call-973574144@munichnet.com 
CSeq: 1 INVITE 

Contact : <sip : ClientB@sv7 1 . gmx . com> 
Content-Length: 0 

30 

Nachricht (3) : 200 OK Client B ~> Client A 
SIP/2.0 200 OK 

From: sip : ClientA@munichnet . com; tag=lc24 84 1 
To: sip : ClientB@gmx . com; tag=0da40dd4-81553525 
35 Call-ID: call-973574144@munichnet.com 
CSeq: 1 INVITE 

Contact : <sip:ClientB@sv71 . gmx. com> 
Content-Type: application/sdp 
Content-Length : 124 

40 

v=0 

o=ClientB 4770 4770 IN IP4 sv71.gmx.com 
s= 

c=IN IP4 178,224.67.133 
45 t=0 0 

m=audio 3456 RTP/AVP 8 
a=rtpmap:8 PCMU/8000 
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Nachricht (4) : ACK Client A -> Client B * 

ACK sip:ClientB@sv7l. gmx.com SIP/2 :0 
From: sip: ClientA@munichnet . com; tag=lc24841 
To: sip:ClientB@gmx.com;tag=0da4 0dd4-81553525 
5 Call-ID: call-973574144@munichnet.com 
CSeq: 1 ACK 
Content-Length: 0 

Nachricht (5) : Re- INVITE Client B -> Client A 
10 INVITE sip: ClientA@pc43.munichnet.com SIP/2.0 

From: sip: ClientBggmx . com; tag=0da40dd4-81553525 

To : sip : ClientA@munichnet . com; tag=lc24841 

Call-ID: call-973574144@munichnet.com 

CSeq: 2 INVITE 
15 Contact: <sip:ClientB@sv71 .gmx.com> 

Content-Type: application/sdp 

Content-Disposition: session; 
action=remote-hold 

Content-Length : 128 

20 

v=0 

o=ClientB 4770 4771 IN IP4 sv71.gmx.com 
s= 

c=IN IP4 0.0.0.0 
25 t=0 0 

a=sendonly 

ra=audio 3456 RTP/AVP 8 
a=rtpmap:8 PCMU/8000 

30 Nachricht (6) : 200 OK Client A -> Client B 
SIP/2.0 200 OK 

From: sip : ClientB@gmx . com; tag=0da4 0dd4-8 1553 525 

To : sip : ClientA@munichnet . com; tag=lc2484i 

Call-ID: call-97357414 4@munichnet.com 
35 CSeq: 2 INVITE 

Contact : <sip : ClientA@pc4 3 . munichnet . com> 

Content-Type: application/sdp 

Content-Disposition : session ; 

action=remote-hold-ack 
4 0 Content-Length: 155 

v=0 

o=ClientA 2890844526 2890844527 IN IP4 pc4 3.munichnet.com 
s= 

45 c=IN IP4 0.0.0.0 
t=0 0 

a=recvonly 

m=audio 49172 RTP/AVP 8 
a=rtpmap:8 PCMA/8000 
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Nachricht (7) : ACK Client B -> Client A 
ACK sip: ClientA@pc43.munichnet.com SIP/2.0 
From: sip: CI ientB@gmx.com; tag=0da40dd4-81553525 
To : sip: CliehtA@munichnet . com; tag=lc24841 
5 Call-ID: call-973574144@munichnet.com 
CSeq: 2 ACK 
Content-Length: 0 

Nachricht (8) : INVITE Client B -> Client C 
10 INVITE sip: ClientC@tomnet.de SIP/2.0 

From: sip: ClientB@gmx.com; tag=0da40dd4-81553526 

To: sip: ClientC@tomnet.de 

Call-ID: call-6789@gmx.com 

CSeq: 10 INVITE 
15 Contact : <sip : ClientB@sv71 . gmx . com> 

Content-Type: application/sdp 

Content-Length : 122 

v=0 

20 o=ClientB 5612 5612 IN IP4 sv71.gmx.com 
s= 

c=IN IP4 178.224.67.133 
t=0 0 

m=audio 34 60 RTP/AVP 8 
25 a=rtpmap:8 PCMU/8000 

Nachricht (9): ,180 Ringing Client C -> Client B 
SIP/2.0 180 Ringing 

From: sip : ClientB@gmx . com; tag=0da4 0dd4-8155352 6 
30 To : sip : ClientC@ tomnet . de ; tag=654 5b243a 
Call-ID: call-6789@gmx.com 
CSeq: 10 INVITE 

Contact : <sip : ClientC@nb23 . tomnet . de> 
Content-Length: 0 

35 

Nachricht (10) : 200 OK Client C -> Client B 
SIP/2.0 200 OK " ' 

From: sip: ClientB@gmx .com; tag=0da40dd4-81553526 
To: sip :ClientC@ tomnet. de; tag=6545b243a 
40 Call-ID: call-6789@gmx.com 
CSeq: 10 INVITE 

Contact; <sip : ClientC@nb23 . tomnet . de> 
Content-Type: application/sdp 
Content-Length : 127 

45 

v=0 

o=ClientC 293845 293845 IN IP4 nb23.tomnet.de 
s= 

C=IN IP4 27.159.111.76 
50 t=0 0 

m=audio 8275 RTP/AVP 8 
a=r t pmap : 8 PCMU/ 8000 
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Nachricht (11) : ACK Client B -> Client C 
ACK sip:ClientC@tomnet.de SIP/2.0 
From: sip: ClientB@gmx.com; tag=0da4 0dd4-8155352 6 
To: sip:ClientC@tomnet.de;tag=6545b243a 
5 Call-ID: call-6789@gmx.com 
CSeq: 10 ACK 
Content-Length: 0 

Nachricht (12) : Re- INVITE Client B -> Client A 
10 INVITE sip: ClientA@pc43.munichnet.com SIP/2.0 

From: sip : ClientB@gmx.com; tag=0da4 0dd4-81553525 

To : sip : ClientA@munichnet . com; tag=lc24841 

Call- ID: call-973574144@munichnet.com 

CSeq: 3 INVITE 
15 Contact : <sip: ClientB@sv71 . gmx . com> 

Content-Type: application/sdp 

Content-Disposition : session; 

action=remote-retrieval ; 
action=redirect-forwards-request 
20 Content-Length: 134 

v=0 

o=ClientB 4770 4772 IN IP4 sv71.gmx.com 
s= 

25 c-IN IP4 27.159.111.76 
t=0 0 

a=sendrecv 

m=audio 8275 RTP/AVP 8 
a=rtpmap:8 PCMU/8000 

30 

Nachricht (13) : 200 OK Client A -> Client B 
SIP/2.0 200 OK ' 
From: sip : ClientB@gmx.com; tag=Oda4 0dd4-8 1553525 
To : sip :ClientA@munichnet . com; tag=lc24841 
35 Call-ID: call-973574144@munichnet.com 
CSeq: 3 INVITE 

Contact : <sip:ClientA@pc43 .munichnet .com> 
Content-Type: application/sdp 
Content-Disposition: session; 
4 0 action=remote-retrieval -ack ; 

action=redirect-bearer-connected-indication 
Content-Length : 172 

v=0 

45 o=ClientA 2890844526 2890844528 IN IP4 pc43.munichnet.com 
s= 

c=IN IP4 192.0.2.101 
t=0 0 

a=sendrecv 
50 m=audio 4 9172 RTP/AVP 8 
a=rtpmap:8 PCMA/8000 
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Nachricht (14) : ACK Client B -> Client A 
ACK sip: ClientA@pc43.munichnet.com SIP/2.0 
From: sip: ClientB@gmx.com; tag=0da4 0dd4-81553525 
To : sip : ClientA@munichnet . com; tag=lc24841 
5 Call-ID: call-973574144@munichnet.com 
CSeq: 3 ACK 
Content-Length: 0 

Nachricht (15) : Re -INVITE Client B -> Client C 
10 INVITE sip:ClientC@nb23. tomnet.de SIP/2.0 

From: sip : ClientB@gmx . com; tag=0da4 0dd4-81 55352 6 

To : sip : ClientC@tomnet . de 

Call-ID: call-6789@gmx.com 

CSeq: 11 INVITE 
15 Contact: <sip:ClientB@sv71 .gmx.com> 

Content-Type : application/sdp 

Content-Disposition: session; 

action=redirect-forwards-request 

Content-Length : 120 

20 

v=0 

o=ClientB 5612 5613 IN IP4 sv71.gmx.com 
s= 

c=IN IP4 192.0.2.101 
25 t=0 0 

m=audio 4 9172 RTP/AVP 8 
a=rtpmap:8 PCMU/8000 

Nachricht (16) : 200 OK Client C -> Client B 
30 SIP/2.0 200 OK 

From: sip: ClientB@gmx . com; tag=Oda40dd4-8 1553526 

To : sip : ClientC@ tomnet . de ; tag=654 5b243a 

Call-ID: call-6789@gmx.com 

CSeq: 11 INVITE 
35 Contact: <sip: ClientC@nb23 .tomnet .de> 

Content-Type: application/sdp 

Content-Disposition: session; 

action=redirect-bearer -connected- i ndi cation 
Content-Length : 127 

40 

v-0 

0=ClientC 293845 293846 IN IP4 nb2 3.tomnet.de 
s= 

c=IN IP4 27.159.111.76 
45 t=0 0 

m=audio 8275 RTP/AVP 8 
a=rtpmap:8 PCMU/8000 
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Nachricht (17) : ACK Client B -> Client C 
ACK sip: ClientC@nb23.toinnet.de SIP/2.0 
From: sip :ClientB@gmx. com; tag==0da40dd4-81553526 
To : sip : ClientC@ tomnet . de; tag=6545b243a 
5 Call-ID: call-6789@gmx.com 
CSeq: 11 ACK 
Content-Length: 0 

Dem Fachmann ist klar, dass die Erfindung selbstverstandlich 
10 nicht nur in den beschriebenen Szenarien, sondern universell 
in alien Szenarien eingesetzt werden kann, in denen das SIP 
oder SIP_T Protokoll verwendet wird. Insbesondere ist ein 
Einsatz in folgenden Szenarien denkbar: 



15 - VoIP Trunking Subscriber <-> VoIP Trunking Subscriber mit 
dem Protokoll SIP_T zur Signalisierung zwischen Control- 
lern MGC 

- SIP Client <-> VoIP Trunking Subscriber 

- SIP Client <-> Access Gateway 
20 - SIP Client <-> H.323 Subscriber 

- SIP Client <-> VoDSL Subscriber (angeschlossen liber ein 
Integrated Access Device IAD bzw. ein Customer Premises 
Gateway CPG) 

- SIP Client <-> SIP Client 

25 

Abschliefiend sei darauf hingewiesen, dass die Beschreibung 
der fur die Erfindung relevanten Komponenten des Kommunikati- 
onsnetzes grundsatzlich nicht einschrankend zu verstehen ist. 
Fur einen einschlagigen Fachmann ist insbesondere offensicht- 

30 lich, dass Begriffe wie Applikation, Client, Server, Gateway, 
Controller, etc... funktional und nicht physikalisch zu ver- 
stehen sind. Somit konnen beispielsweise die Endpunkte A, B 
auch teilweise oder vollstandig in Software / Computerpro- 
grammprodukten P und/oder Uber mehrere physikalische Einrich- 

35 tungen verteilt realisiert werden. 
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Patentanspriiche 

1. SIP Protokoll, 

5 umfassend zumindest ein Protokollelement 2ur Anzeige der 
Ursache(n) einer Bearer Modif ikation. 

2. SIP Protokoll nach Anspruch 1, 

bei dem das Protokollelement in ein Content-Disposition Hea- 
10 der Field gemaB dem Standard RFC2183 eingebettet ist. 

o 

3. SIP Protokoll nach einem der vorstehenden Ansprtiche, 
bei dem das Protokollelement in ein SDP Protokoll nach dem 
Standard RFC2327 eingebettet ist. 

15 

4. SIP Protokoll nach einem der vorstehenden Anspruche, 

bei dem das Protokollelement als Parameter (action) ausgebil- 
det ist, der mehrfach vorgesehen sein kann. 

20 5. SIP Protokoll nach dem vorstehenden Anspruch, 

bei dem der Wertebereich des Parameters zumindest einen der 
folgenden Werte aufweist: connect-backward, connect-forward, 
connect-forward-no-notification, connect- forward-plus- 
notification, connect-forward-no notification-plus-selected 

25 codec, connect forward-plus-notification-plus-selected codec, 
connected, switched, selected-codec, modify-codec, success- 
ful-codec-modification, codec-modification-failure, mid-call- 
codec-negotiation, modify-to-selected-codec-information, mid- 
call-codec-negotiation-failure, redirect-backwards-request, 

30 redirect-forwards-request, redirect-bearer-release-request, 
redirect-bearer-release-proceed, redirect-bearer-release- 
complete, redirect-cut-through-request, redirect-bearer- 
connected-indication, redirect-f ailure, remote-hold, remote- 
hold-ack, remote-retrieval, rernote-retrieval-ack. 
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6. SIP Protokoll nach einem der vorstehenden Anspriiche, 
bei dem das SIP Protokoll nach einem der Standards RFC2543, 
RFC3261 Oder RFC3372 ausgebildet 1st. 

5 7. Verfahren zu Modif ikation eines Bearers in einem Kommuni- 
kationsnetz, bei dem die Ursache der Bearer Modifikation mit 
einem Protokoll nach einem der vorstehenden Protokollansprii- 
che signalisiert wird - insbesondere mit Protokollelementen, 
die im gemaft dem Standard RFC2045 ausgebildeten MIME Message 
10 Body von SIP Messages vorgesehen sind. 

8. Computerprogrammprodukt (P) - insbesondere SIP Client 
Software (SC) -, umfassend Softwarecodeabschnitte, mit denen 
ein Verfahren nach dem vorstehenden Verf ahrensanspruch durch 

15 zumindest einen Prozessor ausgefiihrt wird. 

9. Vorrichtung - insbesondere Controller (MGC) , SIP Telephon 
Oder SIP Proxy (SP) -, umfassend Mittel zur Durchfuhrung 
eines Verfahrens nach dem vorstehenden Verf ahrensanspruch 

20 

10. Anordnung - insbesondere paketorientiertes Netz (IN), 
integriertes Sprach-Daten-Netz (SDN) oder hybrides Netz (IN, 
PSTN) -, umfassend Computerprogrammprodukte und/oder Vorrich- 
tungen zur Durchfuhrung eines Verfahrens nach dem vorstehen- 

25 den Verf ahrensanspruch. 
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